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means capable of interpreting the protocol description language to interpret the protocol description as 

required to communicate using the specific protocol. 
In still another aspect the invention is protocol apparatus for communicating in distributed system, the appa- 
ratus including: 

5 . means for receiving a first general protocol message, the first general protocol message including a pro- 

tocol description which describes a specific protocol and which employs a protocol description language 
which is independent of any particular implementation of the protocol apparatus; and 
. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
10 specific protocol. 

In a further aspect, the invention is apparatus for communicating in a distributed system, the apparatus includ- 
ing: 

. first protocol apparatus for communicating using a general protocol and 
. second protocol apparatus for communicating using the general protocol, 
15 . the first protocol apparatus including 

. means for providing a first general protocol message which includes a protocol description which de- 
scribes a specific protocol and which employs a protocol description language which is independent of 
any particular implementation of the second protocol apparatus; and 
. means for employing the specific protocol to communicate with the second protocol apparatus after pro- 
20 viding the first general protocol message; and 

. the second protocol apparatus including 

. means for receiving the first general protocol message from the first protocol apparatus; and 
. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
25 specific protocol. 

The foregoing and other aspects, objects and advantages of the invention will be apparent to one of ordinary 
skill in the art who peruses the following Drawing and Detailed Description, wherein: 

Brief Description of the Drawing 

30 

FIG. 1 is a block diagram of a typical system in which protocols are used; 
FIG. 2 is a block diagram of a first apparatus incorporating the invention; 
FIG. 3 is a block diagram of a second apparatus incorporating the invention; 
FIG. 4 is a table of instructions in a protocol description language; 
35 FIG. 5 is a flowchart of the bootstrap state; 

FIG. 6 is a flowchart of the error state; 
FIG. 7 is a state diagram for the alternating bit protocol; 

FIG. 8 is a protocol description for the receive side of the alternating bit protocol; 
FIG. 9 is a protocol description for the send side of the alternating bit protocol; 
40 FIG. 10 is a fragment of the transition procedure; 

FIG. 11 is a protocol description for the bootstrap state; 
FIG. 12 is a protocol description for the error state; and 

FIG. 13 is a block diagram of an embodiment which encaches downloaded protocol descriptions. 
The reference numbers employed in the Drawing and the Detailed Description have three or more digits. 
45 The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, 
the element with the reference number "305" is first shown in FIG. 3. 

Detailed Description 

50 The following Detailed Description will first provide an overview of the techniques of the invention and will 

then disclose in detail how the Alternating Bit Protocol (described at Holzmann, supra, pp. 75-77) may be im- 
plemented using the techniques of the invention. 

Overview: FIGs. 1-3 

55 

FIG. 1 is a block diagram of a system 101 in which protocols are used for communication between a first entity 
109(1) and a second entity 109(2). Each entity 109 includes a source or destination 103 for information (INFO) 
105 and a protocol apparatus 107. 
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mentations of protocol apparatus 201 will implement different versions of the protocol. Second, protocol de- 
scription 203 is written only once, but will be used many times. It is therefore worthwhile to expend great efforts 
to ensure that protocol description 203 is in fact a correct, complete and unambiguous description of the pro- 
tocol. Third, the part of protocol apparatus 201 which may differ in the different implementations is protocol 

5 execution device 207. However, protocol execution device 207 must now only be able to correctly execute the 
protocol instructions 205 in protocol description 203. That is, the problem is no longer the correct implemen- 
tation of the protocol, but rather the correct implementation of an instruction set in a single device. This problem 
is, however, far better understood than the problem of implementing a protocol in two devices, and consequent- 
ly, implementations of the protocol instruction set in different protocol apparatuses 201 are far more likely to 

10 be correct than implementations of the protocol itself. 

Apparatus for Executing a General Protocol: FIGs. 3 and 13 

Perhaps the most significant advantage of protocol apparatus 201 is that it can execute any protocol for 
15 which there is a protocol description 203 written in the protocol description language. Consequently, protocol 
apparatus 201 can easily be modified to make a general protocol apparatus which executes a general protocol 
and which can therefore dynamically execute any protocol for which there is a protocol description 203. The 
general protocol is simply the following: 

. in a sending protocol apparatus, sending a general protocol message which includes a protocol descrip- 
20 tion 203; 

. in a receiving general protocol apparatus, employing protocol instruction interpreter 209 to execute the 

protocol description 203 contained in the general protocol message. 
FIG. 3 shows such a general protocol apparatus 301. General protocol apparatus 301 includes protocol 
instruction interpreter memory (PIIM) 309, which contains protocol description 203 for the protocol currently 

25 being executed by protocol apparatus 301 and protocol instruction interpreter data (PIIDATA) 311, which is data 
employed by protocol instruction interpreter 209 in executing protocol description 203. Protocol interpreter 209 
has two additional components: bootstrap component (BOOT) 305 and error component (ERR) 307. These 
components make it possible for general protocol apparatus 301 to execute the general protocol, and thereby 
make it possible for any protocol apparatus 107 which can provide a protocol description 203 to protocol ap- 

30 paratus 301 to use the protocol described in the protocol description 203 to communicate between the entities 
109 to which protocol apparatus 107 and protocol apparatus 301 belong. Of course, both protocol apparatuses 
involved in the communication may be general protocol apparatuses 301. 

Protocol apparatus 301 executes the general protocol as follows: bootstrap 305 listens for a general pro- 
tocol message (indicated by arrow 313) from the other protocol apparatus. In a preferred embodiment, the 

35 general protocol message uses the same path between the protocol apparatuses as does protocol data 111. 
In other embodiments, there may be a special path for the general protocol message. The general protocol 
message further contains at least the first part of protocol description 203 for the specific protocol to be exe- 
cuted. When bootstrap 305 receives the general protocol message, it loads the message into a buffer in pro- 
tocol instruction interpreter data 311 and performs checks as described below. If the message passes the 

40 checks, bootstrap 305 loads the general protocol message into the portion of memory 309 reserved for protocol 
description 203. Thereupon, interpreter 209 begins executing the protocol instructions 205 in the message, 
beginning with the initial instruction. If protocol description 203 is longer than the maximum size of an general 
protocol message, then the first part of protocol description 203 contains protocol instructions which, when 
executed, cause the rest of protocol description 203 to be loaded. 

45 In a preferred embodiment, the general protocol requires that the general protocol message contain check- 

ing information which permits error checking and protocol data information which indicates how protocol in- 
struction interpreter 209 is to interpret protocol data 111 and that the receiving general protocol apparatus 301 
use the checking information and the protocol data information. In the preferred embodiment, there are two 
items of checking information: a checksum for the general protocol message and a required first instruction. 

so On receiving the general protocol message, bootstrap 305 computes the general protocol message's check- 
sum and compares it with the checksum in the message; if they are different, there has been a transmission 
error and bootstrap 305 waits for another general protocol message. If bootstrap 305's check of the required 
first instruction in the general protocol message indicates that the general protocol message is not a protocol 
description 203, the error component 307 of protocol instruction interpreter 209 returns an error message (in- 

55 dicated by arrow 31 5) to the protocol apparatus 101 which provided the general protocol message. Thereupon, 
error 307 waits for a valid general protocol message. Once the general protocol message has been successfully 
received, it is executed by protocol instruction interpreter 209, and as part of the execution, the protocol data 
information in the general protocol message is used to set parameter values in protocol instruction interpreter 
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scription. 

As will be explained in more detail below, the protocol descriptions 203 employed in a preferred embodi- 
ment define a finite state machine. Consequently, a given protocol description 203 is divided into a set of num- 
bered states (S)1321. To permit location of the states, protocol description 1311 is divided into two parts: pro- 
tocol description body (PDB) 1314, which contains the instructions for the states, and state table 1313, which 
relates state numbers to the locations of the corresponding states 1321. There is an entry 1 315 in state table 
1313 for each state 1321 in the protocol description body, and each entry contains the state number (SN) 1317 
and the offset (OFF) 1319 of that state from the beginning of protocol description 1311. 

The modifications required in bootstrap 305 will be immediately apparent from FIG. 13 and the description 
of the general protocol for general protocol apparatus 1323. When a general protocol message is received 
which contains a protocol description identifier for which the protocol description131 1 is in memory 1302. boot- 
strap 305 simply causes interpreter 209 to begin executing the specified protocol description; otherwise, boot- 
strap 305 retains the identifier from the general protocol message and causes error 307 to return an error mes- 
sage and wait for a message which contains the protocol description 1311. When the message arrives, error 
307 causes bootstrap 305 to compare the retained identifier with the identifer in the general protocol message 
containing the protocol description 1311, and if they agree, bootstrap 305 places the protocol description 1311 
in memory 1302 and makes an entry 1305 for the new protocol description 1311 in protocol description table 
1303. 

Of course, many variation on the above arrangements are possible. For example, memory 1302 is nec- 
essarily finite; consequently, bootstrap 305 may have to remove one protocol description 1311 to make room 
for another. One way of doing this would be to include size and most recent use information in protocol de- 
scription table 1303, and bootstrap 305 could use that information to determine which protocol descriptions 
1311 should be removed. Further, the general protocol for general protocol apparatus 1323 might include a 
checksum in the general protocol message for the protocol description 1311 identified by the identifier. Boot- 
strap 305 could use the checksum to make sure that the copy of the protocol description 1 311 in memory 1 302 
was the same as the copy held by the sender. If it was not, bootstrap 305 could send an error message re- 
questing the protocol description and then proceed as previously described for protocol descriptions for which 
there was no copy in memory 1302. 

30 Implementation of Protocol Apparatus 301 

A prototype implementation of protocol apparatus 301 has been constructed in which protocol execution 
device 207 is a computer capable of executing programs written in the well-known "C" programming language. 
In the prototype implementation, protocol instructions 205 belonging to a protocol description language are 

35 interpreted by a protocol instruction interpreter which is written in C and is executed by a process running on 
the computer. General protocol apparatus 301 has been tested by writing a protocol description 203 for the 
alternating bit protocol in the protocol description language and executing the protocol by executing the pro- 
tocol description 203. The following discussion will first disclose the protocol description language, then pro- 
tocol interpreter 209. bootstrap 305, and error component 307. and finally protocol description 203 for the al- 

40 ternating bit protocol. 

The Protocol Description Language: FIG.4 

FIG. 4 shows the instructions in a preferred embodiment of protocol description language 401 . The instruc- 
ts tions fall into two classes: those which perform general stack management and expression evaluation, shown 
in table 403, and those which perform operations which are particularly related to the execution of protocols, 
shown in table 405. 

As is apparent from table 403, protocol instruction interpreter 209 is a stack machine. The stack, maintained 
in protocol instruction interpretation data 311. is a standard integer size push-down stack. The PUSH_BYTE 

50 and PUSH_WORD instructions permit data to be pushed onto the push-down stack. The other instructions 
take their operands and parameters from the top of the stack and push their results back onto the top of the 
stack. When a stack overflow or underflow occurs, interpreter 209 ceases executing the protocol, error com- 
ponent 307 sends an error message to the other protocol apparatus 107, and error component 307 then waits 
for an error handling message from the other protocol apparatus 107. Of course, how the other protocol ap- 

55 paratus 107 responds to the error message is part of the protocol described in protocol description 203. The 
same thing happens if an arithmetic error such as a zero divide or an integer overflow occurs. 

The functions of the instructions in table 405 are generally clear from the table; however, certain instruc- 
tions require a more detailed explanation. Beginning with the instructions in finite state machine control 407, 
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contains the current byte position in the state being executed. At 1006. prot is set to the value of cur_state, 
so that execution starts at the first byte of the state. The while loop indicated at 1007 continues to execute as 
long as prot has a non-0 value, i.e., essentially until a return statement transfers control out of transition. 
The body of the while loop is a switch statement which contains a case for each of the instructions in pro- 

5 tocol description language 401. On each iteration of the loop, the variable prot is incremented by 1. so that it 
points to the next byte in the state. The value of that byte determines which case is executed. If there is no 
case corresponding to that value, default case 1015 is executed, which puts interpreter 209 into the error state 
and thereby transfers control to error 307. Where required, a case further contains debugging code and as- 
sertions to check whether requirements for the execution of the instruction are fulfilled. If interpreter 209 is 

10 only used with fully tested and verified protocol descriptions 203, the assertions and debugging code may be 
disabled. 

Fragment 1001 shows two cases in addition to default case 1015: those for NXT and l_NXT With NXT 
1011, the case simply pops the value at the top of the stack (i.e., the next state), checks whether the value 
is in the range of values for states, and returns the value. With l_NXT, the value of the next state is in the 
15 code, and not on the stack, so the case increments prot by one, checks whether the value at that point in the 
code is within the range, and returns the value. 

Implementation of Bootstrap 305:FIG.5 

20 In a preferred embodiment, Bootstrap 305 is implemented as a state of interpreter 209. Unlike the other states, 
which are defined by the protocol description loaded in by bootstrap 305, bootstrap 305 and error 307 are re- 
quired for the execution of the general protocol and therefore must be built into a protocol apparatus 301 before 
a protocol description 203 can be loaded. 

Since these two states are required for the general protocol, they are the only ones that enforce a prede- 

25 fined format on incoming messages, and that must require, the presence of certain kinds of data to permit 
checking of the general protocol message. As soon as these two states have successfully received a general 
protocol message with protocol description 203, they hand off control of the general protocol apparatus to the 
protocol description 203. 

In a preferred embodiment, bootstrap 305 is implemented with a single call run (BOOTSTRAP). Procedure 
30 run () is the implementation of interpreter 209 in a preferred embodiment. The procedure is reproduced com- 
pletely below. 
run(S) 

{ int n = s; 

while (n >= 0 && n <= SMAX && State[n].cont) 
35 n = transition(n); 

return n; 

} 

run is a loop which invokes the procedure transition with a state number, transition then puts interpreter 209 
into the proper state of protocol description 203 or the states which implement bootstrap 305 or error 307. The 
40 loop ceases execution when a value which is out of range of the legal state numbers is received. Thus, when 
invoked with BOOTSTRAP, a constant indicating the bootstrap state, the run simply puts interpreter 209 into 
the bootstrap state. 

Most of the concepts involved in implementing an embodiment of protocol apparatus 301 can be illustrated 
using an implementation of bootstrap 305. In a protocol apparatus 301 employing such an implementation, the 

45 code for bootstrap 305 would always be present in protocol instruction interpreter memory 309. 

For a general understanding of bootstrap 305, the flow chart of FIG.5 suffices. As shown in oval 503, boot- 
strap implementation 501 waits for the general protocol message from the remote protocol apparatus 107. 
When the message comes, it is loaded into a buffer in protocol instruction interpreter data 311 . Next, the mes- 
sage is checked. First, a checksum is performed, to make sure the message is uncorrupted. If the checksum 

so is non-zero, a transmission error has occurred, and the machine returns to the start of the bootstrap state (di- 
amond 505, 507). If the checksum is zero, a check is made if the message has the correct type (diamond 509). 
In a preferred embodiment, the first instruction is required to be the definition of the BYTEORDER for the lower 
interface. This byte-order definition specifies the order in which the bytes in a word sent according to the pro- 
tocol are transmitted across the lower level interface: most or least significant byte first. It need not match the 

55 byte-order used in either the receiving or the sending entity. If the message is not a valid protocol description 
203, interpreter 209 enters error 307 (511). 

If the message is a valid protocol description 203, the contents of receive buffer is assigned to the initial 
state of the newly loaded protocol, and control is transferred to that state (box 51 5). A full implementation 1101 
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apparatus; and 

employing the specific protocol to communicate with the first protocol apparatus. 

The method set forth in claim 6 further characterized by: 
in the first entity, 

receiving a second general protocol message which indudes a protocol specifier specifying the 
protocol description; 

responding to the second general protocol message by determining whether the specified protocol 
description is accessible to the first entity; 

if the specified protocol description is accessible, employing the first protocol description interpre- 
tation means to interpret the specified protocol description; but 

if the specified protocol description is not accessible, sending a first error message and thereupon 
performing the step of receiving the first general protocol message. 

Protocol apparatus (301) for communicating in a distributed system, the apparatus being characterized 

by: 

means (305) for receiving a first general protocol message, the first general protocol message in- 
cluding a protocol description (203) which describes a specific protocol and which employs a protocol de- 
scription language which is independent of any particular implementation of the protocol apparatus; and 

means (209) for responding to the first general protocol message which are capable of interpreting 
the protocol description language and which interpret the protocol description as required to communicate 
using the specific protocol. 

The protocol apparatus set forth in daim 8 further characterized in that: 

the means for receiving further checks the first general protocol message. 

The protocol apparatus set forth in claim 8 further characterized in that: 

the first general protocol message includes a parameter (415) for interpreting protocol data trans- 
ferred according to the specific protocol; and 

the means for responding to the first general protocol message interprets the protocol data accord- 
ing to the parameter. 

The protocol apparatus set forth in claim 8 further characterized in that: 

the protocol apparatus further includes error handling means (307); 

the means for receiving the first general protocol message further receives a second general pro- 
tocol message including a protocol specifier (1307) specifying the protocol description; and 

the means for responding to the first general protocol message further responds to the second 
general protocol message by determining whether the specified protocol description is accessible and if 
the specified protocol description is accessible, interpreting the specified protocol description, but if the 
specified protocol description is not accessible, sending a first error message. 

Apparatus for communicating in a distributed system, the apparatus being characterized by: 
first protocol apparatus (301) for communicating using a general protocol and 
second protocol apparatus (301) for communicating using the general protocol, 
the first protocol apparatus including 

means (209,903) for providing a first general protocol message which includes a protocol descrip- 
tion (203) which describes a specific protocol and which employs a protocol description language which 
is independent of any particular implementation of the second protocol apparatus; and 

means (209,907) for employing the specific protocol to communicate with the second protocol ap- 
paratus after providing the first general protocol message; and 

the second protocol apparatus induding 

means (301) for receiving the first general protocol message from the first protocol apparatus; and 
means (209) for responding to the first general protocol message which are capable of interpreting 

the protocol description language and which interpret the protocol description as required to communicate 

using the specific protocol. 

Peripheral apparatus for communicating information using a protocol, the apparatus being characterized 
by: 

means (111) for transferring the information according to the protocol; 



13 



EP 0 555 997 A2 



FIG. 1 



v. 



101 



P DATA 

111 



{ 



INFO 105 
CTl 109 



DATA 

S/D(1) 
103(1) 




PA 


s , 


PA 




DATA 

S/0(2) 
103(2) 


T 


107(1) 




107(2) 


■ r 



INFO 
105 

E109(l) 



105 
E1W(2) 



J 



FIG. 2 



PA 201 



r "PO 203" ~ l 
205(0) 



^ 205(n) t j 



PI 



r PED 207 ~1 




PA 301 



FIG. 3 



105 



PI 


y 309 


PD 
203 


Pil DATA 
311 



319^ — 



321 



209 


BOOT 
305 


ERR 
307 


1 

1 


I ». 1 

213 214 




313 


315 


• 111 

1, S 










1 



PED 303 



15 



EP 0 555 997 A2 



FIG. 5 

503»^ flECV^RBUr ) 



jZERO 

509 VAUD MSG? > 

Tyes 



- NXT ERRORSTATE 
511 



513- 



I LOAD 




f RBUF— - STATE 0 





515 



FIG. 6 

1^602 
603 ^H- ERROR MSC TBUF ] 

605 SEND— ^ TBUF J 

T 

609 ^-a^liBiir > NOW - mi0 > N« Wf " 
JzEHO 

6 ,j ^ <tuD 'wsG? > -» ► « Mf™* 

NXT RBUF(1) 
617 



17 



EP 0 555 997 A2 



FIG. 8 
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FIG. 10 
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BYTE bl, *cur_state - State [n] .cont , 
static int Stack tSMAX+1]; 
register BYTE -prot; 1005 
register int w0, wl, w2, i; 
register int «sp - fcStack [SMAX] ; 

^1006 

prot - eur_state;-^ 1 009 

-while (prot) { r ' 

switch («prot++) ( 
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f case NXT : 

assert (sp < 4StacMSMAX] ) ; 

wO - POP; 
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return wO; 
case I_NXT: 
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f default: tw 
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^ return ERRORSTATE; 

} ) 
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(Sh Apparatus and methods for communicating 

Son using any protocol for which there is a 
Socol delation" may be done by mean^ of a 
oeneral protocol. The general protocol nc udes 
I fiit general protocol message whtah .ncludes 
a protocol description for a specific protocol 
The protocol apparatus which receives the first 
pTotoK message employs a protocol descnp- 
Son language interpreter to JfP^J" 
rinded orotocol descnption and tnereDy to 
££5. She specific protocol. The protocol jjj- 

SSTL^i^SST? a? earlier first general 
^rotocoT message and interpreting an encadhed 
protocol description in response to . a """J 
general protocol message which indudes i a 
protocol identifier specifying the encached pro- 
tocol description. 
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